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Abstract 


A message originator sometimes sends content in a form the recipient 
cannot process or would prefer not to process a form of lower quality 
than is preferred. Such content needs to be converted to an 
acceptable form, with the same information or constrained information 
(e.g., changing from color to black and white). In a store-and- 
forward environment, it may be convenient to have this conversion 
performed by an intermediary. This specification integrates two 
ESMTP extensions and three MIME content header fields, which defines 
a cooperative service that permits authorized, accountable content 
form conversion by intermediaries. 
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1. Introduction 


Internet specifications typically define common capabilities for a 
particular service that are supported by all participants. This 
permits the sending of basic data without knowing which additional 
capabilities individual recipients support. However, knowing those 
capabilities permits the sending of additional types of data and data 
of enhanced richness. Otherwise, a message originator will send 
content in a form the recipient cannot process or will send multiple 
forms of data. This specification extends the work of [CONMSG], 
which permits a recipient to solicit alternative content forms from 
the originator. The current specification enables MIME content 
conversion by intermediaries, on behalf of a message originator and a 
message recipient. 
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1.1. Background 


MIME enables the distinguishing and labeling of different types of 
content [IMF, MEDTYP]. However, an email originator cannot know 
whether a recipient is able to support (interpret) a particular data 
type. To permit the basic use of MIME, a minimum set of data types 
is specified as its support base. How will an originator know 
whether a recipient can support any other data types? 


A mechanism for describing MIME types is specified in [FEAT]. 
[CONMSG] specifies a mechanism that permits an originator to query a 
recipient about the types it supports using email messages for the 
control exchange. This permits a recipient to propagate information 
about its capabilities back to an originator. For the control 
exchange, using end-to-end email messages introduces considerable 
latency and some unreliability. 


An alternative approach is for an originator to use the "best" form 
of data that it can, and to include the same types of permitted 
representation information used in [CONMSG]. Hopefully, the 
recipient, or an intermediary, can translate this into a form 
supported by a limited recipient. This specification defines such a 
mechanism. It defines a means of matching message content form to 
the capabilities of a recipient device or system, by using MIME 
content descriptors and the optional use of an SMTP-based negotiation 
mechanism [ESMTP1, ESMTP2]. 


1.2. Overview 


An originator describes desirable content forms in MIME content 
descriptors. It may give "permission", to any intermediary or the 
recipient, to convert the content to one of those forms. Separately, 
an SMTP server may report the target’s content capabilities back to 
the SMTP client. The client is then able to convert the message 
content into a form that is both supported by the target system and 
acceptable to the originator. 


A conversion service needs to balance between directions provided by 
the originator, directions provided on behalf of the recipient, and 
capabilities of the intermediary that performs the conversions. This 
is complicated by the need to determine whether the directions are 
advisory or whether they are intended to be requirements. 

Conversions specified as advisory are performed if possible, but they 
do not alter message delivery. In contrast, conversion 
specifications that are treated as a requirement will prohibit 
delivery if the recipient will not be able to process the content. 
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These possibilities interact to form different processing scenarios, 
in the event that the intermediary cannot satisfy the desires of both 
the originator and the recipient: 

Table 1: FAILURE HANDLING 


\ RECEIVER | 


| | 
+------- + | Advise | Require | 
ORIGINATOR\ | | 

----------- +----------+----------+ 
| Deliver | Deliver | 
Advise | original | original | 
| content | content | 
----------- +----------+----------+ 
| Return | Return | 

Require w/out w/out 

delivery delivery 

----------- +----------+----------+ 


This table reflects a policy that determines failure handling solely 
based on the direction provided by the originator. Thus, information 
on behalf of the recipient is used to guide the details of 
conversion, but not delivery of the message. 


This is intended to continue the existing email practice of 
delivering content that a recipient might not be able to process. 
Clearly, the above table could be modified to reflect a different 
policy. However, that would limit backward compatibility experienced 
by users. 


This specification provides mechanisms to support a controlled, 
transit-time mail content conversion service, through a series of 
mechanisms. These include: 


* an optional ESMTP hop-by-hop service that uses the CONPERM SMTP 
service extensions, issued by the originator, 


* an optional ESMTP hop-by-hop service that uses the CONNEG SMTP 
service extensions, issued on behalf of the recipient, and 


* three MIME Content header fields (Content-Convert, Content- 
Previous and * Content-Features) that specify appropriate 
content header fields and record conversions that have been 
performed. 
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Figure 1: EXAMPLE RELAY ENVIRONMENT 


+------------ + +----------—- + 

| Originator | Recipient | 

+-----------—- + +----------—- + 
| | Posting Delivering/\ 

\/ || 
+-------- + Ho + +-------- + 
SMTP SMTP Relay SMTP 
Client |--->| Server | Client |--->| Server 
+-------- + +-------- +-------- + +-------- + 


1.3. Notational Conventions 


In examples, "C:" and "S:" indicate lines sent by the client and 
server respectively. 


The key words "MUST", "MUST NOT", "SHOULD", “SHOULD NOT" and "MAY" in 
this document are to be interpreted as defined in "Key words for use 
in RFCs to Indicate Requirement Levels" [KEYWORDS]. 


2. Applicability 


This specification defines a cooperative mechanism that facilitates 
early transformation of content. The mechanism can be used to save 
bandwidth and to permit rendering on recipient devices that have 
limited capabilities. In the first case, the assumption is that 
conversion will produce smaller content. In the latter case, the 
assumption is that the recipient device can render content in a form 
derived from the original, but cannot render the original form. 


The mechanism can impose significant resource requirements on 
intermediaries performing conversions. Further, the intermediary 
accepts responsibility for conversion prior to knowing whether it can 
perform the conversion. Also note that conversion is not possible 
for content that has been digitally signed or encrypted, unless the 
converting intermediary can decode and re-code the content. 


3. Service Specification 


This service integrates two ESMTP extensions and three MIME content 
header fields, in order to permit authorized, accountable content 
form conversion by intermediaries. Intermediaries are ESMTP hosts 
(clients and servers) along the transmission path between an 
originator and a recipient. 
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An originator specifies preferred content-types through the Content- 
Convert MIME content header field. The content header fields occur 
in each MIME body-part to which they apply. That is, each MIME 
body-part contains its own record of conversion guidance and history. 


The originator’s preferences are raised to the level of requirement 
through the ESMTP CONPERM service extension. The CONPERM mechanism 
is only needed when an originator requires that conversion 
limitations be enforced by the mail transfer service. If an 
acceptable content type cannot be delivered, then no delivery is to 
take place. 


Target system capabilities are communicated in SMTP sessions through 
the ESMTP CONNEG service extension. This information is used to 
restrict the range of conversions that may be performed, but does not 
affect delivery. 


When CONPERM is used, conversions are performed by the first ESMTP 
host that can obtain both the originator’s permission and information 
about the capabilities supported by the recipient. If a relay or 
client is unable to transmit the message to a next-hop that supports 
CONPERM or to perform appropriate conversion, then it terminates 
message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the 
originator, with status code 5.6.3 (Conversion required but not 
supported). 


When an SMTP relay or server performs content conversion, it records 
which specific conversions are made into Content-Previous and 
Content-Features MIME header fields associated with each converted 
MIME body-part. 


If a message is protected by strong content authentication or privacy 
techniques, then an intermediary that converts message content MUST 
ensure that the results of its processing are similarly protected. 
Otherwise it MUST NOT perform conversion. 


Originator Action: 


An originator specifies desired conversion results through 
the MIME Content-Convert header field. If the originator includes 
a Content-Convert header field, then it must also include a 
Content-Feature header field, to indicate the current form of the 
content. Intermediaries MAY interpret the presence of this header 
field as authorization to perform conversions. When Content- 
Convert header fields are the sole means for guiding conversions 


by intermediaries, then they serve only as advisories. Failure to 
satisfy the guidance of these header fields does not affect final 
delivery. 
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When posting a new message, the originator MAY specify 
transit-service enforcement of conversion limitations by using the 
ESMTP CONPERM service extension. In each of the MIME body-parts 
for which conversion is authorized, conversions MUST be limited to 
those specified in MIME Content-Convert header fields. If 
conversion is needed, but an authorized conversion cannot be 
performed, then the message will be returned to the originator. 

If CONPERM is not used, then failure to perform an authorized 
conversion will not affect normal delivery handling. 


Figure 2: CONPERM USAGE 


4+------------ + 
| Originator | 
4+------------ + 
SMTP | 
or CONPERM 
SUBMIT \/ 
4+-------- + 4+---------------- + 
| SMTP | SMTP | SMTP Relay | 
| Client |----------- >| Server 
+-------- + CONPERM +-------- +------- + 


Recipient Action: 
With the ESMTP mail transfer service, capabilities that can 
be supported on behalf of the recipient SHOULD be communicated to 


intermediaries by the ESMTP CONNEG service extension. 


Figure 3: CONNEG USAGE 


4+----------- + 
| Recipient | 
4+----------- + 
Capabilities| | 
\/ 
4+---------------- + 4+-------- + 
| SMTP Relay | CONNEG | SMTP | 
| | Client |<-------- | Server | 
4+------- 4+-------- + 4+-------- + 


Intermediary Actions: 


An intermediary MAY be given CONPERM direction when receiving 
a message, and MAY be given CONNEG guidance before sending the 
message. CONPERM and CONNEG operate on a per-message basis and 
are issued through the ESMTP MAIL-FROM request. CONNEG response 
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information is provided on a per-recipient basis, through the 
response to ESMTP RCPT-TO. 


Conversion MUST be performed by the first CONPERM 
intermediary that obtains the CONNEG capability information. The 
MIME Content-Type MUST conform to the result of the converted 
content, as per [MEDTYP]. When an intermediary obtains different 
capability information for different recipients of the same 
message, it MAY either: 


* Create a single, converted copy of the content that can be 
supported by all of the recipients, or 


* Create multiple converted copies, matching the capabilities 
of subsets of the recipients. Each version is then sent 
separately to an appropriate subset of the recipients, using 
separate, standard SMTP sessions with separate, standard 
RFC2821.Rcpt-To lists of addresses. 


A record of conversions is placed into MIME Content-Previous 
header fields. The current form of the content is described in 
MIME Content-Features header fields. 


A special case of differential capabilities occurs when an 
intermediary receives capability information about some 
recipients, but no information about others. An example of this 
scenario can occur when sending a message to some recipients 
within one’s own organization, along with recipients located 
elsewhere. The intermediary might have capability information 
about the local recipients, but will not have any for distant 
recipients. This is treated as a variation of the handling that 
is required for situations in which the permissible conversions 
are the null set -- that is, no valid conversions are possible for 
a recipient. 


Rather than simply failing transmission to the recipients for 
which there is no capability information, the intermediary MAY 
choose to split the list of addressees into subsets of separate, 
standard RFC2821.Rcpt-To lists and separate, standard SMTP 
sessions, and then continue the transmission of the original 
content to those recipients via the continued use of the CONPERM 
mechanism. Hence, the handling for such recipients is performed 
as if no CONNEG transaction took place. 


Once an intermediary has performed conversion, it MAY 
terminate use of CONPERM. However, some relay environments, such 
as those re-directing mail to a new target device, will benefit 
from further conversion. Intermediaries MAY continue to use 
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CONPERM or MAY re-initiate CONPERM use when they have knowledge of 
possible variations in a target device. 


NOTE: A new, transformed version of content may have less 
information than the earlier version. Of course, a sequence of 
transformations may lose additional information at each step. 
Perhaps surprisingly, this can result in more loss than might 
be necessary. For example, transformation x could change 
content form A to content form B; then transformation y changes 
B to C. However, it is possible that transformation y might 
have accepted form A directly and produced form D, which has 
more of the original information than C. 


NOTE: An originator MAY validate any conversions that are made 
by requesting a positive [DSNSMTP]. If the DSN request 
includes the "RET" parameter, the delivery agent SHOULD return 
an exact copy of the delivered (converted) message content. 
This will permit the originator to inspect the results of any 
conversion(s). 


3.1. Sending Permission 


A message originator that permits content conversion by 
intermediaries MAY use the CONPERM ESMTP service extension and 
Content-Convert MIME header fields to indicate what conversions are 
permitted by intermediaries. Other mechanisms, by which a message 
originator communicates this permission to the SMTP message transfer 
service, are outside the scope of this specification. 


NOTE: This option requires that a server make an open-ended 
commitment to ensure that acceptable conversions are performed. 
In particular, it is possible that an intermediary will be 
required to perform conversion, but be unable to do so. The 
result will be that the intermediary will be required to 
perform conversion, but it will be performed in undelivered 
mail. 


When an ESMTP client is authorized to participate in the CONPERM 
service, it MUST interact with the next SMTP hop server about: 


* The server’s ability to enforce authorized conversions, through 
ESMTP CONPERM 


* The capabilities supported for the target device or system, 
through ESMTP CONNEG 
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Successful use of CONPERM does not require that conversion take place 
along the message transfer path. Rather, it requires that conversion 
take place when a next-hop server reports capabilities that can be 
supported on behalf of the recipient (through CONNEG) and that those 


capabilities do not include support for the current representation of 
the content. 


NOTE: It is acceptable to have every SMTP server -- 
including the last-hop server -- support CONPERM, with none 
offering CONNEG. In this case, the message is delivered to 
the recipient in its original form. Any possible 
conversions to be performed are left to the recipient. 
Thus, the recipient is given the original form of the 
content, along with an explicit list of conversions deemed 
acceptable by the originator. 


An SMTP server MAY offer ESMTP CONPERM, without being able to perform 
conversions, if it knows conversions can be performed along the 
remainder of the transfer path, or by the target device or system. 


3.2. Returning Capabilities 


A target recipient device or system arranges announcements of its 
content form capabilities to the SMTP service through a means outside 
the scope of this specification. Note that enabling a server to 
issue CONNEG information on behalf of the recipient may require a 
substantial mechanism between the recipient and server. When an 


ESMTP server knows a target’s capabilities, it MAY offer the CONNEG 
ESMTP service extension. 


NOTE: One aspect of that mechanism, between the recipient 
and an ESMTP server offering the CONNEG ESMTP service 
extension could include offering capabilities beyond those 
directly supported by the recipient. In particular, the 
server -- or other intermediaries between the server and the 
recipient -- could support capabilities that they can 
convert to a recipient’s capability. As long as the result 
is acceptable to the set specified in the relevant Content- 
Convert header fields of the message being converted, the 
details of these conversions are part of the 
recipient/server mechanism, and fall outside the scope of 
the current specification. 


If a next-hop ESMTP server responds that it supports CONNEG when a 


message is being processed according to the CONPERM mechanism, then 
the SMTP client: 


1) MUST request CONNEG information 
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2) MUST perform the requisite conversions, if possible, before 
sending the message to the next-hop SMTP server 


3) MUST fail message processing, if any conversion for the message 
fails, and MUST return a failure DSN to the originator with 
status code 5.6.5 (Conversion failed). 


When performing conversions, as specified in Content-Convert MIME 
header fields, the Client MUST: 


1) Add a Content-Previous header field and a Content-Features 
header field to each MIME body-part that has been converted, 
removing any existing Content-Features header fields. 


2) Either: 


* Send a single copy to the next-hop SMTP server, using the 
best capabilities supported by all recipients along that 
path, or 


* Separate the transfers into multiple, standard 
RFC2821.Rcpt-To and ESMTP sessions, in order to provide 
the best conversions possible for subsets of the 
recipients. 


If the transfers are to be separated, then the current session MUST 
be terminated, and new sessions conducted for each subset. 


The conversions to be performed are determined by the intersection of 
three lists: 


* Conversions permitted by the originator 

* Content capabilities of the target 

* Conversions that can be performed by the SMTP client host 
Failed Conversion 

If the result of this intersection is the null set of 

representations, for an addressee, then delivery to that addressee 

MUST be handled as a conversion failure. 


If handling is subject to the CONPERM mechanism and: 


* the next-hop SMTP host does not indicate that it can 
represent the target’s capabilities through CONNEG, but 
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* does respond that it can support CONPERM, then the client 
SMTP MUST send the existing content, if all other SMTP 
transmission requirements are satisfied. 


If handling is not subject to the CONPERM mechanism, then 
conversion failures do not affect message delivery. 


3.3. Next-Hop Non-Support of Service 


If a Client is participating in the CONPERM mechanism, but the next- 
hop SMTP server does not support CONPERM or CONNEG, then the SMTP 
client 


1) MUST terminate the session to the next-hop SMTP server, without 
sending the message 


2) MUST return a DSN notification to the originator, with status 
code 5.6.3 (Conversion required but not supported).  [DSNSMTP, 
DSNFMT, SYSCOD] 


If a Client is participating in the CONPERM mechanism and the next- 

hop SMTP server supports CONNEG, but provides no capabilities for an 
individual RCPT-TO addressee, then the SMTP client's processing for 

that recipient MUST be either to: 


1) Treat the addressee as a conversion failure, or 


2) Separate the addressee from the address list that is processed 
according to CONNEG, and continue to process the addressee 
according to CONPERM. 


4. Content Conversion Permission SMTP Extension 
4.1. Content Conversion Permission Service Extension Definition 
1) The name of the SMTP service extension is 
"Content-Conversion-Permission" 
2) The EHLO keyword value associated with this extension is 
"CONPERM" 


3) A parameter using the keyword "CONPERM" is added to the MAIL-FROM 
command. 


4) The server responds with acceptance or rejection of support for 
CONPERM, for this message. 
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4.2. CONPERM Parameter to Mail-From 
Parameter: 
CONPERM 
Arguments: 
There are no arguments. Specification of permitted 


conversions is located in a Content-Convert header field for each 
MIME body-part in which conversion is permitted. 


Client Action: 


If the server issued a 250-CONPERM as part of its EHLO 
response for the current session, and the client is participating 
in the CONPERM service for this message -- such as by having 
received the message with a CONPERM requirement -- then the client 
MUST issue the CONPERM parameter in the MAIL-FROM. If the server 
does not issue 250-CONPERM, and the client is participating in the 
CONPERM service for this message, then the client MUST treat the 
transmission as permanently rejected. 


Server Action: 
If the client specifies CONPERM in the MAIL-FROM, but the 


server does not support the CONPERM parameter, the server MUST 
reject the MAIL-FROM command with a 504-CONPERM reply. 


If the client issues the CONPERM parameter in the MAIL-FROM, 

then the server MUST conform to this specification. Either it 
MUST relay the message according to CONPERM, or it MUST convert 
the message according to CONNEG information. 

4.3. Syntax 

Content-Conversion-Permission = "CONPERM" 
5. Content Negotiation SMTP Extension 
5.1. Content Negotiation Service Extension Definition 


1) The name of the SMTP service extension is: 


"Content-Negotiation" 
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2) The EHLO keyword value associated with this extension is: 
"CONNEG" 

3) A parameter, using the keyword "CONNEG", is added to the RCPT-TO 
command. 

4) The server responds with a report indicating the content 
capabilities that can be received on behalf of the recipient 
device or system, associated with the target RCPT-TO address. 

52 CONNEG Parameter to RCPT-TO 

Parameter: 

CONNEG 
Arguments: 


There are no arguments. 


Client Action: 


If a message is subject to CONPERM requirements and the 
server issues a 250-CONNEG, as part of its EHLO response for the 
current session, the client MUST issue the CONNEG parameter in the 
RCPT-TO request. If the message is not subject to CONPERM 
requirements, and the server issues a 250-CONNEG, the client MAY 
issue the CONNEG parameter with RCPT-TO. 


If the client issues the CONNEG parameter with RCPT-TO, then 
it MUST honor the capabilities returned in the CONNEG RCPT-TO 
replies for that message. In addition, it MUST convert the 
message content, if the current form of the content is not 
included in the capabilities listed, on behalf of the recipient. 


The conversions that are performed are determined by the 
intersection of the: 


* Conversions permitted by the originator 

* Content capabilities of the target 

* Conversions that can be performed by the SMTP client host 
If the result of this intersection is the null set of 


representations, then the Client processing depends upon whether 
the next-hop server has offered CONPERM, as well as CONNEG: 
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1) If the message will be subject to CONPERM at the next hop, 
the Client MAY transmit the original content to the next hop 
and continue CONPERM requirements. 


2) Otherwise, the Client MUST treat the conversion as failed. 


If the result of the intersection is not null, the client 
SHOULD convert the data to the "highest" level of capability of 
the server. Determination of the level that is highest is left to 
the discretion of the host performing the conversion. 


Each converted MIME body-part MUST have a Content-Previous 
header field that indicates the previous body-part form anda 
Content-Features header field, indicating the new body-part form. 


Server Action: 


If the client specifies CONNEG in the RCPT-TO, but the server 
does not support the CONNEG parameter, the server MUST reject the 
RCPT-TO addressees with 504 replies. 


If the server does support the CONNEG parameter, and it knows 
the capabilities of the target device or system, then it MUST 
provide that information through CONNEG. The server MAY provide a 
broader list than is supported by the recipient if the server can 
ensure that the form of content delivered can be processed by the 
recipient, while still satisfying the constraints of the author’s 
Content-Convert specification(s). 


The response to a CONNEG RCPT-TO request will be multi-line 
RCPT-TO replies. For successful (250) responses, at least the 
first line of the response must contain RCPT-TO information other 
than CONNEG. Additional response lines are for CONNEG. To avoid 
problems due to variations in line buffer sizes, the total 
parametric listing must be provided as a series of lines, each 
beginning with "250-CONNEG", except for the last line, which is 
"250 CONNEG". 


The contents of the capability listing MUST conform to the 
specifications in [SYN] and cover the same range of specifications 
permitted in [CONMSG]. 

5.3. Syntax 
Content-Negotiation = "CONNEG" 


Capability = { <filter> specification, 
as per [SYN] } 
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6. 


MIME Content-Features Header Field 


The Content-Features header field describes the characteristics of 
the current version of the content for the MIME body-part in which 
the header field occurs. There is a separate Content-Features header 
field for each MIME body-part. The specification for this header 
field is contained in [FEAT]. 


MIME Content-Convert Header Field 


Content-Convert is a header field that specifies preferred 
conversions for the associated content. It MAY be used without the 
other mechanisms defined in this document. If present, this header 
field MUST be carried unmodified and delivered to the recipient. In 
its absence, the content originator provides no guidance about 
content conversions, and intermediaries SHOULD NOT perform content 
conversion. 


In the extended ABNF notation, the Content-Convert header field is 
defined as follows: 


Convert = "Content-convert" ":" 

permitted 
Permitted = "ANY" / "NONE" / permitted-list 
permitted-list = { explicit list of permitted 


final forms, using <filter> 
syntax in [SYN] ) 


If the permitted conversions are specified as "ANY", then the 
intermediary may perform any conversions it deems appropriate. 


If the permitted conversions are specified as "NONE", then the 
intermediary SHOULD NOT perform any conversions to this MIME body- 
part, even when the target device or system does not support the 
original form of the content. 


If a Content-Convert header field is present, then a Content-Features 
header field MUST also be present to describe the current form of the 
Content. 


MIME Content-Previous Header Field 


When an intermediary has performed conversion of the associated 
content, the intermediary MUST record details of the previous 
representation, from which the conversion was performed. This 
information is placed in a Content-Previous header field that is part 
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of the MIME body-part with the converted content. There is a 
separate header field for each converted MIME body-part. 


When an intermediary has performed conversion, the intermediary MUST 
record details of the result of the conversion by creating or 
revising the Content-Features header field for the converted MIME 
body-part. 


In the extended [ABNF] notation, the Content-Previous header field is 
defined as follows: 


previous = "Content-Previous" [CFWS] ":" 
[CFWS ] 
date by type 


date = "Date " [CFWS] date-time [CEWS] ";" 
[CFWS ] 

by = "By " [CFWS] domain [CFWS] ";" 
[CFWS ] 

type = { content characteristics, using 


<filter> syntax in [SYN] ) 


The Date field specifies the date and time at which the indicated 
representation was converted into a newer representation. 


The By field specifies the domain name of the intermediary that 
performed the conversion. 


An intermediary MAY choose to derive the Content-Previous header 
field, for a body-part, from an already-existing Content-Features 
header field in that body-part, before that header field is replaced 
with the description of the current representation. 


9. Examples 
9.1. CONPERM Negotiation 


220 example.com IFAX 

EHLO example.com 

250- example.com 

250-DSN 

250 CONPERM 

MAIL FROM:May@some.example.com CONPERM 
250 <May@some.example.com> originator ok 
RCPT TO:<June@some.example.com> 
250-<June@some.example.com> recipient ok 


NANANNNAN 
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C: DATA 
S: 354 okay, send data 
C: <<RFC 2822 message with MIME Content-Type: TIFF-FX 
Per: 
( image-file-structure=TIFF-minimal 
dpi=400 
image-coding=JBIG 
size-x=2150/254 
paper-size=letter 
) 
with MIME body-parts including: 
Content-Convert : 
(& (image-file-structure=TIFF-minimal) 

(MRC-mode=0) 

(color=Binary) 

(| (& (dpi=204) 
(dpi-xyratio=[204/98,204/196]) ) 
(dpi=200) 
(dpi-xyratio=[200/100,1]) ) 

(& (dpi=400) 
(dpi-xyratio=1) ) ) 
(| (image-coding=[MH, MR, MMR] ) 

(& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(IBIG-stripe-size=128) ) ) 

(size-x<=2150/254) 
(paper-size=[letter,A4]) 
(ua-media=stationery) ) 


(€ 


>> 
S: 250 message accepted 
C: QUIT 


S: 221 goodbye 
9.2. Example CONNEG Negotiation 


220 example.com IFAX 

EHLO example.com 

250- example.com 

250-DSN 

250 CONNEG 

MAIL FROM:<May@some.example.com> 

250 <May@some.example.com> originator ok 
RCPT TO:<June@ifaxl.jp> CONNEG 
250-<June@some.example.com> recipient ok 
250-CONNEG (& (image-file-structure=TIFF-minimal) 
250-CONNEG (MRC-mode=0) 

250-CONNEG (color=Binary) 

250-CONNEG (| (& (dpi=204) 


ANNNNANANNNAN 


Toyoda & Crocker Standards Track [Page 18] 


RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005 
S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) ) 
S: 250-CONNEG (& (dpi=200) 

S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) ) 

S: 250-CONNEG (image-coding=[MH, MR, MMR] ) 

S: 250-CONNEG (size-x<=2150/254) 

S: 250-CONNEG (paper-size=[letter,A4]) 

S: 250 CONNEG (ua-media=stationery) ) 

C: DATA 

S: 354 okay, send data 

C: <<RFC 2822 message with MIME Content-Type: TIFF-FX 


10. 


Per: 

( image-file-structure=TIFF-minimal 
dpi=400 
image-coding=JBIG 
size-x=2150/254 
paper-size=letter 

) 

>> 

250 message accepted 
QUIT 

221 goodbye 


Content-Previous 


Content-Previous: 


Date Tue, 1 Jul 2001 10:52:37 +0200; 
By relay.example.com; 
(& (image-file-structure=TIFF-minimal) 

(MRC-mode=0) 

(color=Binary) 

(& (dpi=400) 

(dpi-xyratio=1) ) 

(& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(IBIG-stripe-size=128) ) 

(size-x=2150/254) 

(paper-size=A4) 

(ua-media=stationery) ) 


Security Considerations 


This service Calls for disclosure of capabilities, on behalf of 
recipients. Mechanisms for determining the requestor's and the 


respondent’s authenticated identity are outside the scope of this 
specification. These mechanisms are intended to permit disclosure of 
information that is safe for public distribution; hence, there is no 
inherent need for security measures. 
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Information that should have restricted distribution is still able to 
be disclosed. Therefore, it is the responsibility of the disclosing 
ESMTP server or disclosing ESMTP client to determine whether 
additional security measures should be applied to the use of this 
ESMTP option. 


Use of the ESMTP CONNEG option permits content transformation by an 
intermediary, along the mail transfer path. When the contents are 
encrypted, the intermediary cannot perform the conversion, because it 
is not expected to have access to the relevant secret keying 
material. When the contents are signed, but not encrypted, 
conversion will invalidate the signature. This specification 
provides for potentially unbounded computation by intermediary MTAs, 
depending on the nature and amount of conversion required. Further, 
this computation burden might provide an opportunity for denial-of- 
service attacks, given that Internet mail typically permits 
intermediaries to receive messages from all Internet sources. 


This specification provides for content conversion by unspecified 
intermediaries. Use of this mechanism carries significant risk. 
Although intermediaries always have the ability to perform damaging 
transformations, use of this specification could result in more 
exploration of that potential and, therefore, more misbehavior. Use 
of intermediaries is discussed in [RFC3238]. 


CONPERM/CONNEG provide a cooperative mechanism, rather than enabling 
intermediary actions that were not previously possible. 
Intermediaries already make conversions on their own initiative. 
Hence, the mechanism introduces essentially no security concerns, 
other than divulging recipient preferences. 
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Appendix A. CONNEG with Direct SMTP 


This Appendix is descriptive. It only provides discussion of usage 
issues permitted or required by the normative text 


In some configurations, it is possible to have direct, email-based 
interactions, where the originator’s system conducts a direct, 
interactive TCP connection with the recipient’s system. This 
configuration permits a use of the content form negotiation service 
that conforms to the specification here, but permits some 
simplifications. This single SMTP session does not have the 
complexity of multiple, relaying sessions and therefore does not have 
the requirement for propagating permissions to intermediaries. 


The Originator’s system provides user-level functions for the 
originator, and it contains the SMTP Client for sending messages. 
Hence, the formal step of email "posting" is a process that is 
internal or virtual, within the Originating system. The recipient’s 
service contains the user-level functions for the recipient, and 
contains the SMTP server for receiving messages. Hence, the formal 
steps of email "delivering" and "receipt" are internal or virtual, 
within the Receiving system. 


Figure 4: DIRECT CONNEG 


Originating system Receiving system 
Fs SSR eee SS + Peso Sse E + 
4+------------ + do + 
| Originator | | Recipient | 
| +------------ + | | Ho + | 
| ||Posting | | /\Receiving | 
| V | | [| | 
o + | o + | 

SMTP <---|------- ----| SMTP | 

Client =s 2 ======= ===>] Server 
| aaa + | | ===- + | 
A mnn + AO E + 


In this case, CONPERM is not needed because the SMTP Client is part 
of the originating system and already has the necessary permission. 
Similarly, the SMTP server will be certain to know the recipient's 
capabilities, because the server is part of the receiving system. 


Therefore, Direct Mode email transmission can achieve content 
capability and form matching by having: 
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* Originating systems that conform to this specification and a 
communication process between originator and recipient that is 
the same as would take place between a last-hop SMTP Relay and 
the Delivering SMTP server to which it is connected. 


* That is, the Client and Server MUST employ CONNEG and the 
Client MUST perform any requisite conversions. 


Appendix B. Using Combinations of the Extensions 


This specification defines a number of mechanisms. It is not 
required that they all be used together. For example, the difference 
between listing preferred conversions -- versus specifying enforced 
limitations to conversions -- is discussed in the Introduction. This 
Appendix further describes scenarios that might call for using fewer 
than the complete set defined in this specification. It also 
summarizes the conditions which mandate that an intermediary perform 
conversion. 


This Appendix is descriptive. It only provides discussion of usage 
issues permitted or required by the normative text 


The available mechanisms are: 


1. CONPERM Parameter to Mail-From 
2. CONNEG parameter to RCPT-TO 
3. MIME Content-Convert Header Field 
4. MIME Content-Previous Header Field 
5. MIME Content-Features Header Field 
B.1. Specifying Suggested Conversion Constraints 


Use of the MIME Content-Convert header field specifies the 
originator’s preferences, should conversion be performed. This does 
not impose any requirements on the conversion; it is merely advisory. 


B.2. Specifying Required Conversion Constraints 


When the MIME Content-Convert specification is coupled with the ESMTP 
CONPERM option, then the originator’s specification of preferred 


conversions rises to the level of requirement. No other conversions 
are permitted, except those specified in the Content-Convert header 
field. 


Note that the presence of both mechanisms does not require that 
conversions be performed. Rather, it constrains conversions, 
should they occur. 
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B.3. Accepting All Forms of Content 
Although it is unlikely that any device will always able to process 
every type of existing content, some devices can be upgraded easily 
(e.g., adding plug-in). Hence, such a device is able to process all 
content effectively. 
For such devices, it is better to refrain from issuing a CONNEG 
assertion. Instead, the CONPERM request should be propagated to the 
target device. 

B.4. When Conversion is Required 


A node is required to perform conversion when: 


1. At least one MIME Content-Covert header field is present in the 
message, 


2. ESMTP CONPERM is in force at the node processing the message, 
3. ESMTP CONNEG is also in force at the same node, 
4. The current content form is not cited in the CONNEG list, 


5. At least one content form is present, both in the Content- 
Convert list and the CONNEG list, and 


6. The intermediary is able to convert from the current form to 
one of the forms listed in both Content-Convert and CONNEG. 


Appendix C. MIME Content-Type Registrations 
C.1. Content-Convert 


Header field name: 
Content-Convert 


Applicable protocol: 
Mail (RFC 2822) 


Status: 
Proposed Standard 


Author/Change controller: 
IETF 


Specification document (s): 
RFC 4141. 
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Related information: 
None. 
C.2. Content-Previous 


Header field name: 
Content-Previous 


Applicable protocol: 
Mail (RFC 2822) 


Status: 
Proposed Standard 


Author/Change controller: 
IETF 


Specification document(s): 
RFC 4141, Section 8 


Related information: 
None. 
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